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(3) Industrielle Steuerung mit taktsynchronem Ablaufebenenmodell 

@ Fur jeweils unterschiedliche Steuerungsaufgaben und 
unterschiedliche Randbedingungen bzw. Anforderungen 
des zugrunde liegenden technisches Prozesses wird in 
einfacher und flexibler Weise ein Ablaufebenenmodell fur 
eine industrielle Steuerung (S) vorgeschlagen, das so- 
wohl SPS- als auch MC-Funktionalitat zur Verfugung stellt 
und somit auch fur die Steuerung von Produktionsma- 
schinen geeignet ist. 



Synchron getaktete Ebenen 



Anwenderebene fur Systemexceptions 



ereignisgesteuerte Anwenderebene 



zeitgesteuerte Anwenderebene 



sequentielle Anwenderebene 



zyklische Anwenderebene 



m 

CO 

o 



BUNDESDRUCKEREI 05.02 102 290/217/1 



11 



DE 100 65 

1 

Beschreibung 

[0001] Die Erfindung bezieht sich auf eine industrielle, 
mit einem Runtime- System ausgestattete Steuerung, insbe- 
sondere fur Produktionsmaschinen, wobei das Runtime-Sy- 5 
stem ein Ablaufebenenmodell enthalt, das mehrere Ablauf- 
cbcncn untcrschicdlichcn Typs mit untcrschicdlichcr Priori- 
tat aufweist, wobei eine Ebenengruppe des Runtime-Sy- 
stems aus einem Grundtakt abgeleitete synchron getaktete 
Ebenen enthalt. 10 
[0002] Femer bezieht sich die Erfindung auf die Erstel- 
lung eines Runtime- Systems einer industriellen Steuerung 
mit synchron getakteten System- und Anwenderebenen. 
[0003] Es ist heutzutage iiblich, sowohl fur die speicher- 
programmierbare Steuerung (SPS) als auch fiir die Bewe- 15 
gungssteuerung (MC) jeweils unterschiedliche hierarchi- 
sche Ablaufebenen zu modellieren, denen Software-Tasks 
zur Steuerung des jeweiligen technischen Prozesses zuge- 
ordnet werden. Diese Tasks konnen Systemaufgaben erful- 
len, sie konnen aber auch anwenderprogrammiert sein. 20 
[0004] Aus DE 197 40 550 Al ist es bekannt, dass Pro- 
zess steuerungsfunktionalitaten der speicherprogrammierba- 
ren Steuerungen "SPS" und Bewegungsfunktionalitaten von 
MC-Steuerungen in einem einheitlichen konfigurierbaren 
Steuerungssystem integriert werden konnen. 25 
[0005] Diese SPS/MC -Integration geschieht in Form des 
Zusammenschaltens von SPS- und MC-Steuerungsbaugrup- 
pen. Bei einer sole hen Ausfiihrung der Integration wird aber 
keine optimale und effiziente Taskstruktur fiir die Gesamt- 
heit der Steuerungsaufgaben erreicht. AuBerdem werden bei 30 
dieser Art der Integration hauptsachlich die klassischen 
MC-Funktionalitaten, wie sie insbesondere fiir Werkzeug- 
maschinen relevant sind, unterstutzt. Anforderungen an die 
Steuerung, wie sie aus dem Betrieb von Produktionsmaschi- 
nen bekannt sind, werden durch diese Art des Zusammen- 35 
schaltens von SPS- und MC-Steuerungsbaugruppen nicht 
optimal unterstutzt. 

[0006] In der Anmeldung DE 199 31 933.2 wird vorge- 
schlagen, den Takt des Kommunikations systems zwischen 
dem PC-System und den peripheren Geraten fur einen 40 
Wechsel zwischen einem Echtzeitbetriebsprogramm und ei- 
nem Nicht-Echtzeitbetriebsprogramm heranzunehmen. Hier 
ist es aber die Aufgabe dieser Taktabgreifung aus dem Kom- 
munikationssystem, in einem industriellen Prozess einen 
moglichst reibungslosen Wechsel zwischen Echtzeit- und 45 
Nicht-Echtzeitanwendungen stattfinden zu lassen. Bei die- 
ser Ausgestaltung wird der Grundtakt aber nur aus dem Takt 
des Kommunikationsmediums abgeleitet und er wird nur fiir 
den Wechsel des Betriebssystemmodus eines PC-Systems 
verwendet. 50 
[0007] Der Erfindung liegt daher die Aufgabe zugrunde, 
fiir jeweils unterschiedliche Steuerungsaufgaben und unter- 
schiedliche Randbedingungen bzw. Anforderungen des zu- 
grunde liegenden technischen Prozesses in einfacher Weise 
optimale Auspragungen einer industriellen Steuerung zu er- 55 
stellen, die sowohl SPS- als auch MC-Funktionalitat zur 
Verfiigung stellt und somit auch fur die Steuerung von Pro- 
duktionsmaschinen geeignet ist. 

[0008] Diese optimalcn Auspragungen werden prinzipicll 
durch ein einheitliches konfigurierbares Ablaufebenenmo- 60 
dell fiir die Steuerungs- Tasks der industriellen Steuerung er- 
reicht. 

[0009] Von diesem Ansatz ausgehend wird die oben ge- 
nannte Aufgabe dadurch gelost, dass das Runtime- System 
der industriellen Steuerung ein Ablaufebenenmodell enthalt, 65 
das mehrere Ablaufebenen unterschiedlichen Typs mit un- 
terschiedlicher Prioritat aufweist, wobei folgende Ablauf- 
ebenen vorgesehen sind: 
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a) eine Ebenengruppe mit aus einem Grundtakt abge- 
leiteten synchron getakteten Ebenen, bestehend aus 
mindestens einer Systemebene und mindestens einer 
Anwenderebene, wobei die Ebenen dieser Ebenen- 
gruppe untereinander eine Priorisierung aufweisen 
konnen, 

b) einer Anwenderebene fiir Systcmcxccptions, 

c) einer ereignisgesteuerten Anwenderebene, 

d) einer zeitgesteuerten Anwenderebene, 

e) einer sequentiellen Anwenderebene, 

f) einer zyklischen Anwenderebene, 

wobei Anwenderebenen der Ebenengruppe a) optional syn- 
chron zu einer der Systemebenen der Ebenengruppe a) lau- 
fen konnen. 

[0010] Ein wesentlicher Vorteil dieser Schichtung liegt 
darin, dass die Kommunikation zwischen den Tasks der Pro- 
zesssteuerung (SPS) und denen der Bewegungs steuerung 
(MC) minimiert wird. Ein weiterer Vorteil liegt darin, dass 
die Programmierung der Steuerungsaufgaben fiir die Pro- 
zesssteuerung und fiir die Bewegungs steuerung in einer ein- 
heitlichen Programmiersprache mit einer einheitlichen Er- 
stelloberflache erfolgen kann und dass der Anwender ein fur 
seine jeweiligen Anforderungen zugeschnittenes Ablauf- 
ebenenmodell flexibel erstellen kann. 

[0011] Eine erste Ausgestaltung der vorliegenden Erfin- 
dung liegt darin, dass der Grundtakt des Ablaufebenenmo- 
dells aus einem internen Timer oder aus einem internen Takt 
eines Kommunikationsmediums oder aus einem externen 
Gerat oder von einer GroBe, die zum technologischen Pro- 
zess gehort, ableitbar ist. Dadurch kann sehr flexibel und 
sehr einfach der Grundtakt fiir das Ablaufebenenmodell ab- 
geleitet werden. Dadurch, dass der Grundtakt fiir das Ab- 
laufebenenmodell auch von einer GroBe, die zum technolo- 
gischen Prozess gehort, ableitbar ist, kann auf eine sehr ein- 
fache Weise eine direkte Riickkopplung aus dem technolo- 
gischen Prozess zur Steuerung erhalten werden. 
[0012] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass die ereignisgesteuerte Anwender- 
ebene, die zeitgesteuerte Anwenderebene, die sequentielle 
Anwenderebene, die zyklische Anwenderebene und die An- 
wenderebene fiir System Exceptions optional sind. Der An- 
wender kann sich dadurch sehr flexibel eine Steuerung er- 
stellen, die fiir seine konkreten vorliegenden Anforderungen 
sehr effizient ist und die die gerade benotigten Ablaufebenen 
enthalt und somit keinen unnotigen Overhead beinhaltet. 
[0013] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass die synchronen Ebenen zum Grund- 
takt ubersetzt und/oder untersetzt und/oder im Verhaltnis 
1 : 1 getaktet sind. Dadurch konnen die Ebenen jeweils sehr 
leicht zu einem Vielfachen des Grundtaktes getaktet werden 
oder aber auch jeweils zu einem reziproken Vielfachen ge- 
taktet werden. Ausgehend von einer gemeinsamen Aus- 
gangsgroBe konnen somit sehr einfach Ubersetzungen, aber 
auch Untersetzungen fiir die jeweiligen Ebenen erreicht 
werden. 

[0014] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass weitere priorisierende Schichtungen 
inner halb der Ablaufebenen vorgesehen sind. Die S oft war c- 
struktur der industriellen Steuerung lasst sich dadurch opti- 
mal an die unterschiedlichen Steuerungsaufgaben bzw. an 
die Anforderungen des zugrunde liegenden technischen Pro- 
zesses anpassen. Somit lassen sich z. B. unterschiedliche 
Fehlerursachen unterschiedlichen Ebenen mit z. B. aufstei- 
gender Prioritat zuordnen. 

[0015] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass optional Anwender-Tasks beim Sy- 
stemhochlauf und/oder beim Systemrunterfahren durchlauf- 
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bar sind. Dadurch konnen beim Systemhochlauf z. B. Initia- 
lisierungsfunktionen angestoBen werden oder beim System- 
runterfahren kann durch Anwenderprogrammierung sicher- 
gestellt werden, dass die im System vorhandenen Achsen 
eine definierte Position einnehmen. 5 
[0016] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung licgt darin, dass in die Anwcndcrcbcncn Anwender- 
programme ladbar sind. Dadurch kann der Anwender in sei- 
nen Anwenderprogramrnen die Funktionalitat der Steuerung 
sehr flexibel an die zugrunde liegenden Anforderungen des 10 
technischen Prozesses anpassen und er kann auch die An- 
wenderprogramme in unterschiedliche Anwenderebenen la- 
den, um dadurch eine fur seine jeweiligen Applikationen ef- 
fektive Auspragung der Steuerung zu erreichen. 
[0017] Eine weitere vorteilhafte Ausgestaltung der Erfin- 15 
dung liegt darin, dass in die Anwenderebenen Anwender- 
programme ladbar sind, die je nach Typ der Anwenderebene 
zyklusorientiert oder sequentiell prograrnmiert sind. Der 
Anwender kann somit in ein einheitliches Ablaufebenenmo- 
dell bzw. Runtime-System einer industriellen Steuerung so- 20 
wohl zyklusorientierte Anwenderprogramme (z. B. typische 
SPS-Funktionalitat) als auch sequentielle bzw. ablauforien- 
tierte Anwenderprogramme (z. B. typische Bewegungs- 
Funktionalitat) laden. Ein Anwender kann somit nach unter- 
schiedlichen Paradigmen programmierte Programme (zy- 25 
klusorientiert fiir SPS-Funktionalitat und sequentiell bzw. 
ablauforientiert fiir Bewegungsfunktionalitat) sehr flexibel 
und konform in die Anwenderebenen des Ablaufebenenmo- 
dells hinzuladen. Zyklusorientierte Programme sind typi- 
scherweise zykluszeituberwacht. 30 
[0018] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass durch das Hinzuladen von Technolo- 
giepaketen in die Systernebenen die technologische Funk- 
tionalitat der Steuerung erweiterbar ist. Damit. kann der An- 
wender ausgehend von einem Basissystem der Steuerung 35 
den Befehlsvorrat dieses Basissystems dynamisch zuge- 
schnitten auf die jeweiligen Erfordernissen des zugrundelie- 
genden technologischen Prozesses oder der Steuerungsauf- 
gabe erweitern. Das Basissystem bildet hierbei den Auslie- 
ferungsumfang des Run-Time-Systems einer Steuerung, 40 
namlich ein Echtzeitbetriebssy stern, ein Ablaufsystem (mit 
System- und Anwenderebenen), Sprachbefehle, den SPS- 
Befehlsvorrat sowie Kommunikations- (z. B. LAN, E/A) 
und technologische Schnittstellen (z. B. Antriebe, Geber) 
zum technischen ProzeB. Im Basissystem befindet sich so- 45 
mit die notwendige Grundfunktionalitat einer Steuerung. 
Das Basissystem ist dabei auf unterschiedlichsten HW-Platt- 
formen (z. B. PC-based, Drive-based, Controller-based) ab- 
lauffahig. Durch das Zuladen von Technologiepaketen hat 
ein Anwender somit die Moglichkeit einer Skalierung des 50 
Run-Time- Systems der Steuerung. 

[0019] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt, dass Mechanismen bereitgestellt sind, die es ei- 
nem Anwender ermoglichen, im Programmzyklus auf eine 
beliebige Bedingung zu warten, wobei bei Erfulltsein der 55 
Bedingung der Prograrnmfluss unmittelbar fortsetzbar ist, 
bei Nichterfiilltsein der Bedingung der Prograrnmfluss so 
lange angehalten wird, bis das Erfulltsein der Bedingung 
fcstgcstcllt wird, wobei beim Warten auf das Erfulltsein der 
Bedingung die Prioritat der Bedingungsiiberpriifung im Ver- 60 
gleich zur aktuellen Taskprioritat erhoht wird. Durch diesen 
Mechanismus wird es ermoglicht, eine zusammengehorige 
und geschlossene Aufgabenstellung in einem Stuck Code ei- 
nes Anwenderprogrammes auszudriicken, ohne dass weitere 
Mechanismen wie z. B. Event-Handler erforderlich sind. 65 
Dadurch wird einerseits in der Steuerung Verwaltungs- 
Overhead vermieden, was direkt die System-Performance 
erhoht und andererseits aus programmierlechnischer Sicht 
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das Lokalitatsprinzip unterstiitzt, wodurch z. B. das Debug- 
ging erleichtert wird. 

[0020] Der beschriebene Mechanismus und der dazugeho- 
rige Befehl werden im weiteren als "wait_for-condition" be- 
zeichnet. 

[0021] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung licgt darin, dass fiir die Formulicrung der Bcdingungcn 
Prozesssignale und/oder interne Signale der Steuerung und/ 
oder Variablen aus Anwenderprogramrnen verwendbar sind. 
Dadurch ist es dern Anwender moglich, bei der Beschrei- 
bung der Bedingungen Prozesssignale, interne Steuerung s- 
signale oder Anwendervariablen in einer einheitlichen 
Weise zu verbinden. 

[0022] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass verschiedene Ablaufebenen zur Verfii- 
gung stehen, die in Vielfachen eines Grundtaktes abgearbei- 
tet werden, wobei technologische Funktionen den Ablauf- 
ebenen frei zugeordnet werden. Achsen und technologische 
Ablaufe erfordern unterschiedliche Genauigkeit und Reakti- 
onsfahigkeit. Sie konnen daher unterschiedlichen Taktra- 
stern (z. B. eine Achse wird im 1 ms Takt gerechnet, eine 
andere im 2 ms Takt). Im Sinne einer geringeren Gesamtbe- 
lastung des Runtime-Systems bzw. des gesamten S)'stems 
werden durch die vorliegende Ausgestaltung die entspre- 
chenden Tasks nur so hochprior bearbeitet, wie notwendig. 
[0023] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass das Runtime- System der Steuerung 
ein Ablaufebenenmodell enthalt, das mehrere Ablaufebenen 
unterschiedlichen Typs mit unterschiedlicher Prioritat auf- 
weist, wobei folgende Ablaufebenen vorgesehen sind: 

a) Eine Ebene, die bei Technologiefehlern aktiviert 
wird, 

b) eine Ebene, die bei Zykluszeitiiberwachung der 
Hintergrund-Tasks aktiviert wird, 

c) eine Ebene, die bei Programmfehlern aktiviert wird, 

d) eine Ebene, die bei Systemfehlern aktiviert wird, 

e) eine Ebene, die bei Fehlern oder Alarmen in der Pe- 
ripherie aktiviert wird, 

f) eine Ebene, die beim Ansprechen von Zeitiiberwa- 
chungen aktiviert wird, 

g) mindestens eine Ebene, die beim Erkennen von An- 
wender- Interrupts aktiviert wird, 

h) eine Interpolatorebene, 

i) mindestens eine Ebene fur Timer-Interrupts, 

j) mindestens eine Ebene fur die, vorzugsweise se- 
quentielle, Abarbeitung von Bewegungs-Tasks und 
k) eine Ebene fiir die Hintergrund-Bearbeitung, 

wobei weitere Anwender-Tasks beim Systemhochlauf und/ 
oder beim Systemrunterfahren durchlaufen werden. Durch 
diese Ausgestaltung der Ablaufebenenstruktur wird insbe- 
sondere ein sehr effizientes Runtime-System fiir industrielle 
Steuerungen fiir Produktionsmaschinen erreicht. 
[0024] Eine weitere vorteilhafte Ausgestaltung der Erfin- 
dung liegt darin, dass der Grundtakt des Ablaufebenenmo- 
dells aus einem internen Timer oder aus einem internen Takt 
eines Kommunikationsmediums oder von einer GrbBe, die 
zum technologischen Prozcss gchort, abgclcitct wird. Ein 
Anwender hat somit groBe Flexibility, den Grundtakt zu er- 
zeugen. Der Grundtakt kann z. B. aus aquidistanten Bussy- 
stemen wie z. B. Profibus sehr leicht abgeleitet werden. 
[0025] GemaB der Erflndung wird die oben genannte Auf- 
gabe fiir ein Verfahren der eingangs genannten Art durch die 
folgenden aufeinander folgenden Schritte gelost: 

a) Taktgenerierung aus einem internen Hardware-Takt 
oder einem Kommunikations system oder einer GroBe 
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eines technologischen Prozesses, 

b) Bereitstellen von System- und Anwenderebenen fur 
das Runtime- System, die zu diesem Grundtakt syn- 
chronisierte Ablaufebenen bereitstellen, 

c) Bereitstellen mindestens einer Anwenderebene, die 5 
synchron zu der bzw. den Systemebenen integriert ist 
und 

d) Programmieren der Anwenderebene bzw. der An- 
wenderebenen. 

10 

[0026] Ein Anwender kann dadurch auf eine definierte Art 
und Weise ein Runtime-System einer industriellen Steue- 
rung mit synchron getakteten System- und Anwenderebenen 
erstellen, das Prozesssteuerungsfunktionalitaten von spei- 
cherprogrammierbaren Steuerungen "SPS" und Bewe- 15 
gungsfunktionalitaten von MC-Steuerungen integriert, wo- 
bei die dazugehorige Taktgenerierung sehr einfach erreicht 
wird. 

[0027] Ein Ausfuhrungsbei spiel der Erfindung ist in der 
Zeichnung dargestellt und wird im folgenden erlautert. 20 
[0028] Dabei zeigen: 

[0029] Fig. 1 die wesentlichen Ablaufebenen einer klassi- 
schen speicherprogrammierbaren Steuerung, 
[0030] Fig, 2 die wesentlichen Ablaufebenen einer Bewe- 
gungs steuerung, 25 
[0031] Fig. 3 die erfindungsgemaBe industrielle Steue- 
rung, 

[0032] Fig, 4 das Ablaufebenenmodell dieser industriellen 
Steuerung, 

[0033] Fig. 5 ein Ausfuhrungsbeispiel fur das Zuladen 30 
von Anwenderprogrammen in die Anwenderebenen, 
[0034] Fig. 6 ein Ausfuhrungsbeispiel fiir den Gebrauch 
und den Mechanismus des Wait_for_Condition-Befehls, im 
Ablaufebenenmodell der erfindung sgemaBen industriellen 
Steuerung, 35 
[0035] Fig. 7 in einer Schemadarstellung Moglichkeiten, 
wie der Grundtakt fiir die industrielle Steuerung gewonnen 
wird und 

[0036] Fig. 8 zeigt als 00(objektorientiert)-Strukturdia- 
gramm ein Technologiepaket, bestehend aus Code-Anteil, 40 
Parameter, Firmw are- Konfigu ration, Technologieobjekttyp, 
Sprachmechanismen und Deklarationsteil. 
[0037] In der Darstellung gemaB Fig. 1 sind die wesentli- 
chen Ablaufebenen einer klassischen speicherprogrammier- 
baren Steuerung (SPS), angeordnet nach ihrer Prioritat, ge- 45 
zeigt. Der Prioritatsanstieg ist dabei durch einen Pfeil sym- 
bolisiert. In der niederpriorsten Ebene werden, wie durch 
eine gestrichelte Linie angedeutet, zwei unterschiedliche 
Aufgaben, namlich ein freier Zyklus, d. h. "Anwenderebene 
freier Zyklus" und eine Hintergrund-Systemebene, d. h. 50 
"Systemebene Hintergrund" abgewickelt. Der Hintergrund- 
Systemebene sind z. B. Kommunikations aufgaben zugeord- 
net. Bei einer folgenden Anwenderebene, bezeichnet als 
"Anwenderebene zeitgesteuert", ist der Aufruftakt der Tasks 
bzw. der Programme dieser Ebene parametrierbar. Es erfolgt 55 
eine Uberwachung dahingehend, ob die Bearbeitung eines 
Anwenderprogrammes dieser getakteten Ebene rechtzeitig 
abgeschlossen ist, bevor das Startereignis erneut auftritt. 
Lauft die Taktzcit ab, ohnc dass das Anwcndcrprogramm 
der zugeordneten Ebene fertig abgearbeitet ist, wird eine 60 
entsprechende Task einer prioritatsmaBig ubernachsten 
"Anwenderebene fur asynchrone Fehler" gestartet. In dieser 
"Anwenderebene fiir asynchrone Fehler" kann der Anwen- 
der die Behandlung von Fehlerzustanden ausprogrammie- 
ren. 65 
[0038] Auf die "Anwenderebene zeitgesteuert" folgt eine 
"Anwenderebene Events". Die Reaktion auf externe oder in- 
terne Ereignisse (Events) erfolgt innerhalb der "Anwender- 



ebene Events". Ein typisches Beispiel fur ein solches Ereig- 
nis ist das Schalten eines binaren bzw. digitalen Eingangs, 
wodurch typischerweise ein Ereignis ausgelost wird. In ei- 
ner "Systemebene hochprior" liegen die Aufgaben des Be- 
triebssy stems, welche die Arbeits weise der programmierba- 
ren Steuerung (SPS) sicherstellen. 

[0039] Die Darstellung gemaB Fig. 2 zeigt die wesentli- 
chen Ablaufebenen einer Be wegungssteuerung (MC). Auch 
hierbei sind die einzelnen Ebenen nach ihrer Prioritat hierar- 
chisch, wie durch einen Pfeil symbolisiert, angeordnet. Eine 
"Systemebene Hintergrund" und eine "Anwenderebene se- 
quentiell" haben eine gleiche Prioritat, namlich die niedrig- 
ste. Diese aufgabenmaBige Zugehorigkeit ist wie bei Fig. 1 
durch eine gestrichelte Linie symbolisiert. Die Tasks der 
"Anwenderebene sequentiell" werden zusammen mit den 
Tasks der "Systemebene Hintergrund" im Round-Robin- 
Verfahren abgearbeitet. Typische Tasks der "Systemebene 
Hintergrund" sind z. B. solche fiir Kommunikations aufga- 
ben. In der "Anwenderebene sequentiell" laufen die vom 
Anwender programmierten Programmteile fiir die eigentli- 
che Steuerungsaufgabe. StoBt die Steuerung in einem dieser 
Programmteile auf einen Bewegungs- oder Positionierbe- 
fehl, wird ein "Suspend" gesetzt, d. h. das Anwenderpro- 
gramm wird an dieser Stelle unterbrochen. In diesem Fall 
wird ein Befehl synchron genutzt. Die Abarbeitung dieses 
Bewegungs- oder Positionierbefehls geschieht in einer 
hochstprioren "Sj^stemebene getaktet". Ein jeder Lageregler 
oder Interpolator, der in der "Systemebene getaktet" ablauft, 
fiihrt diesen Bewegungs- bzw. Positionierbefehl aus. Nach 
Ausfiihrung des Befehls wird in die "Anwenderebene se- 
quentiell" zuriickgesprungen und das durch "Suspend" un- 
terbrochene Anwenderprogramm wird durch ein "Resume" 
an der gleichen Stelle fortgesetzt. Die "Systemebene getak- 
tet" enthalt neben den schon erwahnten Lagereglern auch 
den Interpolationsteil der Steuerung. 

[0040] Auf die niederpriorste Ebene setzt die "Anwender- 
ebene Events" auf. Hier sind solche Tasks untergebracht, die 
auf externe oder interne Ereignisse reagieren. Solche Ereig- 
nisse konnen beispielsweise Alarme sein. 
[0041] In einer folgenden "Anwenderebene synchronge- 
taktet" laufen synchron getaktete Anwender- Tasks ab, z. B. 
Reglerfunktionalitaten. Diese Tasks sind synchronisiert zu 
getakteten Systemfunktionen wie zum Beispiel Interpolator, 
Lageregler oder zyklische Buskommunikation. 
[0042] In der Darstellung gemaB Fig. 3 wird in Form eines 
Strukturbildes gezeigt, dass die Steuerung eines technischen 
Prozesses PI iiber das Runtime-System RTS einer indu- 
striellen Steuerung erfolgt. Die Verbindung zwischen dem 
Runtime- System RTS der Steuerung und dem technischen 
Prozess PI geschieht bidirektional iiber die Ein-/Ausgang 
EA. Die Programmierung der Steuerung und damit das Fest- 
legen des Verhaltens des Runtime-Systems RTS geschieht 
im Engineering-System Es. Das Engineering-System ES 
enthalt Werkzeuge fiir die Konfigurierung, Projektierung 
und Programmierung fiir Maschinen bzw. fiir die Steuerung 
technischer Prozesse. Die im Engineering-System erstellten 
Programme werden iiber den Informationspfad I in das Run- 
time-System RTS der Steuerung iibertragen. Beziiglich sei- 
ner Hardwarc-Ausstattung bestcht ein Engineering- System 
ES iiblicherweise aus einem Computersystem mit Graphik- 
bildschirm (z. B. Display), Eingabehilfsmitteln (z. B. Tasta- 
tur und Maus), Prozessor, Arbeits- und Sekundarspeicher, 
einer Einrichtung fiir die Aufnahme computerlesbarer Me- 
dien (z. B. Disketten, CDs) sowie Anschlusseinheiten fur ei- 
nen Datenaustausch mit anderen Systemen (z. B. weiteren 
Computersystemen, Steuerungen fiir technische Prozesse) 
oder Medien (z. B. Internet). Eine Steuerung besteht iibli- 
cherweise aus Eingabe- und Ausgabeeinheiten, sowie aus 
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Prozessor und Programmspeicher. Es ist auch vorstellbar, 
dass die Steuerung eines technischen Prozesses PI iiber 
mehrere Runtime-Systeme RTS von industriellen Steuerun- 
gen erfolgt. 

[0043] Die Darstellung gemaB Fig. 4 zeigt das Ablaufebe- 5 
nenmodell der industriellen Steuerung. Die Priorisierung 
dcr Ebcncn wird durch cincn Pfcil in Richtung zur hochstcn 
Prioritat angedeutet. Die niederpriorsten Ebenen sind die 
"zyklische Anwenderebene" und die "sequentielle Anwen- 
derebene". Diese beiden Ebenen laufen mit der gleichen 10 
Prioritat. Deshalb sind diese Ebenen in der Darstellung ge- 
maB Fig. 4 durch eine gestrichelte Linie getrennt. Die "zy- 
klische Anwenderebene" beinhaltet die "Background Task", 
die zykluszeitiiberwacht ist. In der " sequentiellen Anwen- 
derebene" werden die "Motion Tasks" durchlaufen. "Motion 15 
Tasks" sind nicht zykluszeitiiberwacht und dienen im We- 
sentlichen zur Beschreibung sequentieller Ablaufe. "Motion 
Tasks" werden quasiparallel abgearbeitet. Generell enthal- 
ten alle Anwenderebenen eine oder mehrere Tasks. Die 
Tasks nehmen die Anwenderprogramme auf. Die Tasks der 20 
"zyklische Anwenderebene" und der "sequentiellen Anwen- 
derebene" werden in einem gemeinsamen Round-Robin-Zy- 
klus abgearbeitet. 

[0044] Die nachstfolgende Ebene ist die "zeitgesteuerte 
Anwenderebene". Die Tasks dieser Ebene werden zeitge- 25 
steuert aktiviert. Die Zeitsteuerung ist einer Granularitat von 
Millisekunden einstellbar. Auf die "zeitgesteuerte Anwen- 
derebene" folgt die "ereignisgesteuerte Anwenderebene". In 
dieser Ebene werden nach Erkennen eines User Interrupts so 
genannte "User Interrupt Tasks" aktiviert. User Interrupt Er- 30 
eignisse konnen als logische Verkniipfung von Prozessereig- 
nissen und/oder internen Zustanden formuliert werden. 
[0045] Die nachsthohere Ebene ist die "Anwenderebene 
fiir System Exceptions". In dieser "Anwenderebene fur Sy- 
stem Exceptions" werden System Interrupts iiberwacht, bei 35 
deren Eintreffen so genannte "Exceptions", d. h. Ausnahme- 
fallbehandlungen, generiert werden. In der "Anwender- 
ebene fiir System Exceptions" gibt es z. B. folgende Tasks, 
die bei Auftreten eines entsprechenden System Interrupts 
aktiviert werden: 40 

a) "Time Fault Task", die beim Ansprechen von Zeit- 
iiberwachungen aktiviert wird, 

b) "Peripheral Fault Task", die z. B. bei Prozess- und 
Diagnosealarmen aktiviert wird, aber auch bei Stati- 45 
onsausfall oder Stations wiederkehr, 

c) "System Fault Task", die bei allgemeinen System- 
fehlern aktiviert wird, 

d) "Program Fault Task", die bei Programmierfehlern 

(z. B. Division durch Null) aktiviert wird, 50 

e) "Time Fault Background Task", die beim Anspre- 
chen der Zykluszeituberwachung der Background Task 
aktiviert wird und 

f) "Technological Fault Task", die bei Technologiefeh- 
lern aktiviert wird. 55 

[0046] Als nachstes folgt die Ebenengruppe " synchron ge- 
taktete Ebenen". Diese Ebenengruppe besitzt die hochste 
Prioritat im Ablaufebenenmodell. Die cinzclncn Ebcncn 
dieser Ebenengruppe konnen untereinander weitere Priori- 60 
sierungen aufweisen. Die Ebenengruppe "synchron getak- 
tete Ebenen" besteht aus mindestens einer Systemebene und 
mindestens einer Anwenderebene. Die Systemebenen bein- 
halten die Systemfunktionen wie z. B. Lageregler oder In- 
terpolator. In die Anwenderebenen dieser Ebenengruppe 65 
konnen von einem Anwender flexibel Anwenderprogramme 
(AP1-AP4; Fig. 5) zugeladen werden. 

[0047] Fiir die Taktung der "synchron getakteten Ebenen" 
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gibt es eine Reihe unterschiedlicher Taktgenerierungsmog- 
lichkeiten. Der Grundtakt kann z. B. aus einem internen Ti- 
mer (Tl; Fig. 7) kommen oder aus einem internen Takt (T3; 
Fig. 7) eines Kommunikationsmediums (z. B. Profibus) 
oder aber der Takt kann auch aus einem Prozessereignis des 
technologischen Prozesses abgeleitet werden. Ein solches 
Prozessereignis kann z. B. die Taktratc (TG; Fig. 7) cincs 
Vorgangs an einer Produktionsmaschine oder Verpackungs- 
maschine sein. Anwenderebenen der Ebenengruppe "syn- 
chron getaktete Ebenen" konnen dabei basierend auf dem 
Grundtakt getaktet werden, sie konnen aber auch synchron 
zu einer der Systemebenen der Ebenengruppe "synchron ge- 
taktete Ebenen" laufen. Die Anwendertasks dieser zu einer 
Systemebene synchronen Anwenderebene haben somit eine 
synchrone, d. h. deterministische Beziehung zu einer vom 
Anwender flexibel festlegbaren Systemebene. Das hat den 
Vorteil, dass deterministische Reaktionen auf Systemtasks 
(Systemtasks laufen in den Systemebenen), die der Anwen- 
der in seinen Anwendertasks programmiert hat, die in den 
Anwenderebenen der Ebenengruppe "synchron getaktete 
Ebenen" laufen, vom System garantiert werden. Das heiBt 
z. B., dass das System garantiert, dass diese "synchrone An- 
wenderebene" entsprechend beispielhaft vor dem Interpola- 
tor aktiviert wird oder aber auch vor einer beliebigen ande- 
ren Systemfunktion. 

[0048] Die "zeitgesteuerte Anwenderebene", die "ereig- 
nisgesteuerte Anwenderebene", die "sequentielle Anwen- 
derebene", die "zyklische Anwenderebene" sowie die "An- 
wenderebene fiir System Exceptions" sind optional. 
[0049] Die Task der "zyklischen Anwenderebene" (Back- 
ground Task) ist zykluszeitiiberwacht. Die "Motion Tasks" 
dagegen sind nicht zykluszeitiiberwacht und dienen im we- 
sentlichen zur Beschreibung sequentieller Ablaufe. Das 
heiBt, das vorliegende Ablaufebenenmodell unterstutzt ei- 
nen Anwender sowohl bei der Programmierung von sequen- 
tiellen Ablaufen als auch bei der Ereignisprogrammierung. 
Es konnen somit synchrone Ereignisse als auch asynchrone 
Ereignisse durch die Programmierung erfasst werden. In die 
Anwenderebenen sind die vom Anwender erstellten Anwen- 
derprogramme (AP1-AP4; Fig. 5) zuladbar. Die Anwender- 
programme API bis AP4 werden ublicherweise mit Hilfe ei- 
ner Programmierumgebung des Engineering-Systems (ES 
Fig. 3) erstellt. 

[0050] Die Darstellung gemaB Fig. 5 zeigt ein Ausfiih- 
rungsbeispiel fur das Zuladen von Anwenderprogramm in 
die Anwenderebenen. Fig. 5 zeigt exemplarisch eine Aus- 
pragung von Anwenderebenen des Ablaufebenenmodells. 
Durch die drei Punkte am unteren Rand der Zeichnung ist 
dargestellt, dass auch noch weitere Anwenderebenen, aber 
auch Systemebenen vorhanden sein konnen. Die Priorisie- 
rung der Ebenen wird wie im Vorangegangenen durch einen 
Pfeil in Richtung zur hochsten Prioritat angedeutet. Den An- 
wenderebenen werden die Anwenderprogramme API bis 
AP4, am rechten Bildrand durch kleine Rechtecke angedeu- 
tet, zugeordnet. Die Zuordnnng wird dargestellt durch Zu- 
ordnungspfeile ZP1 bis ZP4. In den Anwenderebenen befin- 
den sich Tasks, die die zugeladenen Anwenderprogramme 
API bis AP4 aufnehmen. Diese Tasks werden dann nach ei- 
ner gewissen Strategic (z. B. scqucnticll) durchlaufen bzw. 
abgearbeitet. 

[0051] Die Darstellung gemaB Fig. 6 zeigt ein Ausfiih- 
rungsbeispiel fiir den Gebrauch und den Mechanismus des 
Wait_for_Condition-Befehls, im Ablaufebenenmodell der 
erfindungs gemaB en industriellen Steuerung. Der 
Wait_for_Condition-Befehl (in Fig. 6 dargestellt als 
wait_for_cond()) wird in dieser Darstellung exemplarisch in 
der "sequentiellen Anwenderebene" verwendet. Der 
Wait_for_Condition-Befehl wird in den vom Anwender er- 
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stellten "Motion Tasks" MT1 und MT2 verwendet, die Be- 
standteil der "sequentiellen Anwenderebene" sind. Die 
"Motion Tasks" MT1 und MT2 hangen in einem Round- Ro- 
bin-Zyklus, dargestellt durch den Pfeil von MT1 nach MT2 
und durch den abgewinkelten Pfeil von MT2 zu MT1. Die 5 
drei Punkte innerhalb dieses Pfeiles deuten an, dass noch 
wcitcrc "Motion Tasks" im Round-Robin-Zyklus hangen 
konnen. Die "Motion Task" MT1 enthalt den Wait_for_Con- 
dition-Befehl n wait_for_cond(cond_l)", die "Motion Task" 
MT2 den Wait_for-Condition-Befehl 10 

"wait_for_cond(cond_2) n . Jeweils drei Punkte, die inner- 
halb von MT1 bzw. MT2 verwendet werden, deuten an, dass 
neben den beiden Wait_for_Condition-Befehlen und den 
drei Positionierbefehlen posl() bis pos3() noch weitere Be- 
fehle in den "Motion Tasks" enthalten sein konnen. 15 
[0052] Insgesamt besteht das in Fig. 6 exemplarisch dar- 
gestellte Ablaufebenenmodell eines Runtime-Systems fiir 
eine industrielle Steuerung aus folgenden Ebenen (aufge- 
zahlt von niedrigster bis hochster Prioritat): "zyklische An- 
wenderebene", "sequentielle Anwenderebene" (die Tasks 20 
dieser beiden Ebenen haben die gleiche Prioritat, dargestellt 
durch die gestrichelte Linie zwischen diesen Ebenen), "zeit- 
gesteuerte Anwenderebene", "ereignisgesteuerte Anwen- 
derebene", "Anwenderebene fur Systemexceptions", "syn- 
chron getaktete Anwenderebene 2", "synchron getaktete 25 
Anwenderebene 1", "synchron getaktete Systemebene 2" 
und als hochstpriore Ebene eine "synchron getaktete Sy- 
stemebene 1". 

[0053] Die Arbeitsweise des Wait_for_Condition-Befehls 
wird beispielhaft an M wait_for_cond(cond_l)" aus der "Mo- 30 
tion Task" MT1 gezeigt. 1st die "Motion Task" MT1 im 
Round-Robin-Zyklus an der Reihe, werden die Befehle der 
"Motion Task" MT1 solange bedient, bis die Zeitscheibe ab- 
gelaufen ist, oder eine Unterbrechung komrnt. Trifft dies zu, 
wird die "Motion Task" MT2 als nach ste Task im Zyklus be- 35 
dient, usw. Wird in der "Motion Task" MT1 der 
wait_for_cond(cond_l)-Befehl abgearbeitet, wird die Be- 
dingung cond_l uberpruft. Ist cond_l = true, also erfullt, 
dann wird sofort der nachstfolgende Befehl pos2() ausge- 
fiihrt und eventuell weitere in MT1 vorhandene Befehle 40 
sukzessive abgearbeitet, bis die Kontrolle an die nachste 
Task abgegeben wird. 

[0054] Ist die Bedingung cond_l = false, also nicht erfullt, 
wird sofort die "Motion Task" MT1 unterbrochen und im 
Round-Robin-Zyklus wird MT2 bedient. Die Bedingung 45 
cond_l wird aber in die "synchron getaktete Systemebene 
2" eingehangt (angedeutet durch den durchgehenden abge- 
winkelten Pfeil vom wait_for_cond(cond_l)-Befehl zu der 
"synchron getakteten Systemebene 2") und im Takt dieser 
Systemebene auf ihr Erfulltsein uberpruft. Ist die Bedingung 50 
cond_l erfullt, wird im Round-Robin-Zyklus die aktuelle 
Task verdrangt, d. h. ihr wird die Zeitscheibe entzogen und 
die Motion Task MT1 wird sofort unmittelbar nach dem 
wait for cond(cond l) mit dem Positionierbefehl pos2() 
fortgesetzt. Durch den gestrichelten Pfeil wird der Riick- 55 
sprung aus der "synchron getakteten Systemebene 2" zum 
Positionierbefehl pos2(), d. h. zur " sequentiellen Anwender- 
ebene" angedeutet. 

[0055] Dadurch, dass bci Nichtcrfulltscin der Bedingung 
des Wait_for_Condition-Befehls die I Jberpriifung der Be- 60 
dingung in einer hochprioren "synchron getakteten System- 
ebene" stattfindet, und bei Erfulltsein der Bedingung sofort 
die unterbrochene "Motion Task" fortgesetzt wird, ist es ei- 
nem Anwender moglich, bei der Programmierung von Be- 
wegungssequenzen extrem zeitkritische Applikationen mit 65 
einfachen Sprachmitteln zu spezifizieren. Die Performance 
und Deterministik wird noch dadurch erhoht, dass beim 
Uberprufen der Bedingungen in den jeweiligen hochprioren 



419 A 1 

10 

"synchron getakteten Systemebenen" nur aktuell anstehende 
Bedingungen eingehangt und beriicksichtigt werden. 
[0056] Der hier beschriebene Mechanismus erfordert auch 
keinen expliziten Event-Handler. Der groBe Vorteil aus An- 
wendersicht liegt somit darin, dass der Anwender jetzt in ei- 
nem sequentiellen Ablaufprogramm auf einer relativ niedri- 
gen Prioritatscbcnc einer "Motion Task" in scincm Pro- 
grammfluss hochpriore Ereignisse mit Hilfe von Programm- 
konstrukten formulieren kann und nicht in ein anderes Pro- 
gramm wechseln muss, das er dann liber andere Mechanis- 
men (z. B. per Hand oder interruptgesteuert) auf synchrone 
Anwendertask abbilden muss, sondern er hat die Moglich- 
keit, in einem geschlossenen Anwenderprogramm diesen 
Zyklus "Warten auf hochpriores Ereignis" und "hochpriore 
Reaktion" auf dieses Ereignis in einem Programm geschlos- 
sen zu formulieren. 

[0057] Die Bedingungen, die in einem Wait for Condi- 
tion-Befehl abgefragt werden, konnen vom Anwender sehr 
flexibel und elegant formuliert werden. So kann der Anwen- 
der zur Formulierung dieser Bedingungen Programmvaria- 
blen aus einem Anwenderprogramm verwenden oder in- 
terne GroBen der Steuerung oder er kann auch Prozesssi- 
gnale referenzieren. Diese GroBen konnen dann logisch, 
arithmetisch oder mit beliebigen Funktionen inhaltlich ver- 
knupft werden, um daraus eine Bedingung zu formulieren. 
Neben dem hochprioren Abfragen, ob die Bedingung erfullt 
ist, kann man sich auch vorstellen, dass bei Erfulltsein der 
Bedingung auch noch dazugehoriger Programmcode, d. h. 
eine dahinterliegende Reaktion, die anwenderprogrammier- 
bar ist, hochprior ausgefiihrt wird. Und dass erst nach der 
Ausfuhrung dieses Prograrnmcodes der Riicksprung in die 
niederpriore Ebene erfolgt. 

[0058] Darstellung gemaB Fig. 7 zeigt in einer Schema- 
darstellung Moglichkeiten, wie der Grundtakt fiir die indu- 
strielle Steuerung gewonnen wird. Fig. 7 zeigt exemplarisch 
eine Kommunikationstopologie, in die die Steuerung S inte- 
griert ist. Die Steuerung S ist durch ein Rechteck dargestellt. 
Durch eine Anschlussleitung A2 ist die Steuerung S mit dem 
Bus Bl verbunden, an dem uber eine Anschlussleitung Al 
das externe Gerat EG hangt. Uber den Bus B2 erfolgt die 
Verbindung zum technischen Prozess P2. Der technische 
Prozess P2 ist am unteren Bildrand durch ein Rechteck dar- 
gestellt. Uber die Anschlussleitung A3 ist die Steuerung S 
mit dem Bus B2 verbunden, der wiederum uber die An- 
schlussleitung A4 die Verbindung zum technischen Prozess 
P2 herstellt. 

[0059] Die Generierung fiir den Grundtakt der Steuerung 
S kann aus unterschiedlichen Taktquellen erfolgen. So z. B. 
aus einer internen Taktquelle, dargestellt durch den internen 
Timer T2 der Steuerung S oder auch durch eine externe 
Taktquelle wie z. B. den Timer Tl, der zum externen Gerat 
EG gehort. Als externe Taktquelle kann aber auch der 
Grundtakt eines Kommunikationsmediums dienen. Wenn 
der Bus B2 z. B. durch einen aquidistanten Profibus reali- 
siert wird, dann kann der Takt fiir die Steuerung aus dem 
Grundtakt dieses Busses gewonnen werden. In Fig. 7 ist dies 
dargestellt dadurch, dass der Timer T3 direkt an der An- 
schlussleitung A3 positioniert ist, und diese Anschlusslei- 
tung A3 stcllt die Verbindung zum Bus B2 her. Die Steue- 
rung hangt somit als Slave am Bus und kann direkt den Bu- 
stakt verwenden. Es gibt mehrere Varianten, wie der Takt fiir 
die Steuerung aus dem Grundtakt eines Kommunikations- 
mediums (z. B. eines Busses) gewonnen werden kann: 
Zum einen kann die Steuerung S Slave am Bus sein, die 
Taktinformation kommt dann von extern uber den Bus. Zum 
anderen kann die Steuerung S Master am Bus sein. Die Takt- 
quelle liegt in diesem Fall in der Steuerung S. Fiir diesen 
Fall existieren zwei Auspragungen. Die Taktquelle kann in 



DE 100 65 

11 

einer Masterbusanschaltung liegen oder die Taktquelle ist in 
der Steuerung S. hierbei erfolgt die Einspeisung des Taktes 
in die Masterbusanschaltung. 

[0060] Weiterhin kann als exteme Taktquelle ein Taktge- 
ber TG dienen, der im technischen Prozess P2 integriert ist. 5 
Ein Taktgeber TG in einem technischen Prozess kann z. B. 
der Arbcitstakt cincr Produktionsmaschinc oder Vcrpak- 
kungsmaschine sein. In der Darstellung gemaB Fig. 7 sind 
als Kommunikationsmedien beispielhaft Busverbindungen 
dargestellt. Es konnen aber als Kommunikationsmedien 10 
aber auch Ring-, Stern- oder andere Verbindungsarten ge- 
wahlt werden, auch wireless-Verbindungen. Aus diesen Ver- 
bindungssystemen kann dann der oben genannte Grundtakt 
abgeleitet werden. 

[0061] Die Darstellung gemaB Fig, 8 zeigt als OO-Struk- 15 

turdiagramm, wobei die dazugehorigen Kardinalitaten 
durch eine gangige Ziffern-Notation angezeigt werden, ein 
Technologiepaket TP mit seinen Bestandteilen: 

a) Ablauffahige Code-Teile (Code) 20 

b) Parameter (PAR) 

c) Firmware-Konfiguration (FWK) 

d) Mindestens einem Technologieobjekttyp (TO) 

e) Sprachmechanismen (SPR) 

f) Deklarations- und Beschreibungsteil (ACC) 25 

[0062] Die 1 bis n Code-Teile (z. B. C-Funktionen) wer- 
den beispielsweise fur die Bewegungsfiihrung oder die La- 
geregelung oder fur eine andere Technologie verwendet. Die 
Code-Teile konnen unter anderem Befehle fiir Temperatur- 30 
fiihrung, Temperaturregelung oder fiir spezielle Technolo- 
gien wie z. B. Pressen oder Kunststoffverarbeitung beinhal- 
ten. Wie diese Code-Teile im Ablaufebenenmodell der 
Steuerung in die Systemebenen eingehangt werden und in 
welcher Reihenfolge sie zur Abarbeitung, d. h. Ausfiihrung, 35 
gelangen sollen, wird in der Firmware-Konfiguration FWK 
festgelegt. In dieser steht also die Information, in welche Sy- 
stemebene ein Code-Teil integriert werden soil und wenn in 
einer Systemebene mehrere Code-Teile integriert sind, in 
welcher Reihenfolge diese Code-Teile abgearbeitet werden 40 
sollen. 

[0063] Der Parameter-Teil PAR beinhaltet Oberflachen 
(Masken, Combo-Boxen, Regeln fiir die, Abhangigkeit der 
Parameter untereinander, etc.) fiir das Engineering- System 
(ES; Fig. 3) als auch die Mechanismen fiir das Runtime-Sy- 45 
stem (RTS; Fig. 3), die eine Parametrierung ermoglichen. 
Damit hat der Anwender die Moglichkeit, Instanzen von 
Technologieobjekttypen TO eines Technologiepaketes TP 
gemaB seinen Anforderungen zu parametrieren. 
[0064] Mit Hilfe der 1 bis n Sprachmechanismen SPR ei- 50 
nes Technologiepakets TP laBt sich der Sprachvorrat des En- 
gineering-Systems (ES; Fig. 3) um Befehle und Operatoren, 
die fiir das zugrundeliegende Technologiepaket TP mit sei- 
nen zugehorenden 1 bis n Technologieobjekttypen TO ad- 
aquat und sinnvoll sind, erweitern. Sprachmechanismen 55 
SPR miissen ins Engineering- System (ES; Fig. 3) und ins 
Runtime-System (RTS; Fig. 3) der Steuerung geladen wer- 
den. Nachdem solche Sprachmechanismen (z. B. "erhohe 
Temperatur") im Engineering-System (ES; Fig. 3) installicrt 
wurden, sind sie im Compiler und in der Oberflache bzw. im 60 
Browser des Engineering-Systems (ES; Fig. 3) bekannt und 
konnen vom Anwender in seinen Anwenderprogrammen di- 
rekt verwendet werden. Durch eine Plug & Play-Technolo- 
gie wird sichergestellt, daB im Engineering-System (ES; 
Fig. 3) bekannte Sprachmechanismen auch als ablauffahi- 65 
ges Codestiick im Runtime-System (RTS; Fig. 3) vorhanden 
sind. Der Anwender verwendet also die Spezifikation der 
Sprachmechanismen, um die Implementierung im Runtime- 
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System (RTS; Fig. 3) braucht er sich nicht mehr zu kiim- 
mern. In der ACC-Komponente eines Technologiepakets TP 
befindet sich die Beschreibung aller Sprachelemente, die 
das Technologiepaket TP enthalt, die Beschreibung aller Sy- 
stemvariablen und aller Typen, die im Technologiepaket TP 
verwendet werden. Die ACC-Komponente entspricht somit 
einem Deklarations- und Beschreibungsteil fiir das Techno- 
logiepaket TP. Diese ACC-Komponente wird in erster Linie 
ins Runtime- System (RTS; Fig. 3) der Steuerung geladen. 
Dadurch wird sichergestellt, daB sich alle Informationen 
bzgl. vorhandener Technologiepaketen TP und Technolo- 
gieobjekttypen TO im Runtime-System der Steuerung befin- 
den und somit der AnschluB von Bedien- und Beobach- 
tungsgeraten (z. B. Operator Panels) sehr leicht moglich ist. 

Patentanspriiche 

1. Industrielle, mit einem Runtime-System (RTS) aus- 
gestattete Steuerung (S), insbesondere fur Produktions- 
maschinen, wobei das Runtime-System (RTS) ein Ab- 
laufebenenmodell enthalt, das mehrere Ablaufebenen 
unterschiedlichen Typs mit unterschiedlicher Prioritat 
aufweist, wobei folgende Ablaufebenen vorgesehen 
sind: 

a) eine Ebenengruppe mit aus einem Grundtakt 
abgeleiteten synchron getakteten Ebenen, beste- 
hend aus mindestens einer Systemebene und min- 
destens einer Anwenderebene, wobei die Ebenen 
dieser Ebenengruppe untereinander eine Priorisie- 
rung aufweisen konnen, 

b einer Anwenderebene fiir Systemexceptions 

c) einer ereignisgesteuerten Anwenderebene, 

d) einer zeitgesteuerten Anwenderebene, 

e) einer sequentiellen Anwenderebene, 

f) einer zyklischen Anwenderebene, 

wobei Anwenderebenen der Ebenengruppe a) optional 
synchron zu einer der Systemebenen der Ebenengruppe 
a) laufen konnen. 

2. Industrielle Steuerung nach Anspruch 1, dadurch 
gekennzeichnet, dass der Grundtakt des Ablaufebenen- 
modells aus einem internen Timer (T2) oder aus einem 
interaen Takt (T3) eines Kommunikationsmediums 
(Bl, B2) oder aus einem externen Gerat (EG) oder von 
einer GroBe (TG), die zum technologischen Prozess 
(PI, P2) gehort ableitbar ist. 

3. Industrielle Steuerung nach Anspruch 1 oder An- 
spruch 2, dadurch gekennzeichnet, dass die ereignisge- 
steuerte Anwenderebene, die zeitgesteuerte Anwender- 
ebene, die sequentielle Anwenderebene, die zyklische 
Anwenderebene und die Anwenderebene fiir System- 
exceptions optional sind. 

4. Industrielle Steuerung nach einem der vorstehenden 
Anspriiche, dadurch gekennzeichnet, dass die synchro- 
nen Ebenen zum Grundtakt ubersetzt und/oder unter- 
setzt und/oder im Verhaltnis 1 : 1 getaktet sind. 

5. Industrielle Steuerung nach einem der vorstehenden 
Anspriiche, dadurch gekennzeichnet, dass weitere prio- 
risierende Schichtungen innerhalb der Ablaufebenen 
vorgesehen sind. 

6. Industrielle Steuerung nach einem der vorstehenden 
Anspriiche, dadurch gekennzeichnet, dass optional An- 
wendertasks beim Systemhochlauf und/oder beim Sy- 
stemrunterfahren durchlaufbar sind. 

7. Industrielle Steuerung nach einem der vorstehenden 
Anspriiche, dadurch gekennzeichnet, dass in die An- 
wenderebenen Anwenderprogramme (AP1-AP4) lad- 
bar sind. 

8. Industrielle Steuerung nach einem der vorstehenden 
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Anspriiche, dadurch gekennzeichnet, dass in die An- 
wenderebenen Anwenderprogramme (AP1-AP4) lad- 
bar sind, die je nach Typ der Anwenderebene zyklus- 
orientiert oder sequentiell programmiert sind. 

9. Industrielle Steuerung nach einem der vorstehenden 5 
Anspriiche, dadurch gekennzeichnet, dass durch das 
Hinzuladcn von Tcchnologicpakctcn (TP) in die Sy- 
stemebenen die technologische Funktionalitat der 
Steuerung (S) erweiterbar ist. 

10. Industrielle Steuerung nach einem der vorstehen- 10 
den Anspriiche, dadurch gekennzeichnet, dass Mecha- 
nismen bereitgestellt sind, die es einem Anwender er- 
moglichen im Programmfluss auf eine beliebige Bedin- 
gung zu warten, wobei bei Erfiilltsein der Bedingung 
der Programmfluss unmittelbar fortsetzbar ist, bei 15 
Nichterfiilltsein der Bedingung der Programmfluss so- 
lange angehalten wird, bis das Erfiilltsein der Bedin- 
gung festgestellt wird, wobei beim Warten auf das Er- 
fiilltsein der Bedingung die Prioritat der Bedingungs- 
iiberpriifung im Vergleich zur aktuellen Taskprioritat 20 
erhoht wird. 

11. Industrielle Steuerung nach Anspruch 10, dadurch 
gekennzeichnet, dass fur die Formulierung der Bedin- 
gungen Prozesssignale und/oder interne Signale der 
Steuerung und/oder Variablen aus Anwenderprogram- 25 
men (AP1-AP4) verwendbar sind. 

12. Industrielle Steuerung nach einem der vorstehen- 
den Anspriiche, dadurch gekennzeichnet, dass ver- 
schiedene Ablaufebenen zur Verfiigung stehen, die in 
Vielfachen eines Grundtaktes abgearbeitet werden, wo- 30 
bei technologische Funktionen den Ablaufebenen frei 
zugeordnet werden. 

13. Industrielle Steuerung nach einem der vorstehen- 
den Anspriiche, dadurch gekennzeichnet, dass das 
Runtime- System (RTS) der Steuerung (S) ein Ablauf- 35 
ebenenmodell enthalt, das mehrere Ablaufebenen un- 
terschiedlichen Typs mit unterschiedlicher Prioritat 
aufweist, wobei folgende Ablaufebenen vorgesehen 
sind: 

a) eine Ebene, die bei Technologiefehlern akti- 40 
viert wird, 

b) eine Ebene, die bei Zykluszeitiiberwachung 
der Hintergrund- Tasks aktiviert wird, 

c) eine Ebene, die bei Programmfehlern aktiviert 
wird, 45 

d) eine Ebene, die bei Systemfehlern aktiviert 
wird, 

e) eine Ebene, die bei Fehlern oder Alarmen in 
der Peripherie aktiviert wird, 

f) eine Ebene, die beim Ansprechen von Zeit- 50 
iiberwachungen aktiviert wird, 

g) mindestens eine Ebene, die beim Erkennen 
von Anwender-Interrupts aktiviert wird, 

h) eine Interpolatorebene, 

i) mindestens eine Ebene fur Timer-Interrupts, 55 
j) mindestens eine Ebene fur die, vorzugsweise 
sequentielle, Abarbeitung von Bewegungs-Tasks 
und 

k) cine Ebene fur die Hintergrund- Bcarbcitung, 
wobei weitere Anwendertasks beim Systemhochlauf 60 
und/oder beim Systemrunterfahren durchlaufen wer- 
den. 

14. Industrielle Steuerung nach Anspruch 13, dadurch 
gekennzeichnet, dass der Grundtakt des Ablauf ebenen- 
modells aus einem internen Timer (T2) oder aus einem 65 
internen Takt (T3) eines Kommunikationsmediums 
(Bl, B2) oder aus einem externen Gerat (EG) oder von 
einer GroBe (TG), die zum technologischen Prozess 
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(PI, P2) gehort abgeleitet wird. 

15. Verfahren zur Erstellung eines Runtime-Systems 
(RTS) einer industriellen Steuerung (S) mit synchron 
getakteten System- und Anwenderebenen nach einem 
der vorstehenden Anspriiche, gekennzeichnet durch 
folgende aufeinander folgenden Schritte: 

a) Taktgcncricrung aus einem internen HW-Takt 
(T2) oder einem Kommunikationssystem (Bl, 
B2) oder einen externen Gerat (EG) oder einer 
GroBe (TG) eines technologischen Prozesses (PI, 
P2), 

b) Bereitstellen von System- und Anwenderebe- 
nen fur das Runtime-System (RTS) die zu diesem 
Grundtakt synchronsierte Ablaufebenen bereit- 
stellen, 

c) Bereitstellen mindestens eine Anwenderebene, 
die synchron zu der bzw. den Systemebenen inte- 
griert ist und 

d) Programmierbaren der Anwenderebene bzw. 
der Anwenderebenen. 
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